Systems and methods for context-aware message tagging

ABSTRACT

Disclosed are systems, apparatus, and methods for context-aware messaging. In various implementations, a conversation between two or more users may be hosted by a communications tool, where the conversation generates text included in a conversation thread. Information and entities may be extracted from the generated text. One or more weights may be assigned to each of the extracted plurality of entities based on the contents of the conversation thread. The one or more weights may provide a rank for each of the extracted entities for a search of at least one information feed. In some implementations, the at least one information feed may be searched based on the weighted extracted entities to identify at least one relevant information feed. The at least one relevant information feed may be updated with the information extracted from the conversation thread.

CLAIM OF PRIORITY

This application claims the benefit of U.S. Provisional PatentApplication 61/601,909 entitled SYSTEMS AND METHODS FOR CONTEXT-AWAREMESSAGE TAGGING, by Rajaram Satyanarayanan, filed Feb. 22, 2012,(Attorney Docket No. 818PROV), the entire contents of which areincorporated herein by reference.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

FIELD OF THE INVENTION

One or more implementations relate generally to computer systems andsoftware, and, more particularly, to online social networking andmessaging systems.

BACKGROUND

The subject matter discussed in the background section should not beassumed to be prior art merely as a result of its mention in thebackground section. Similarly, a problem mentioned in the backgroundsection or associated with the subject matter of the background sectionshould not be assumed to have been previously recognized in the priorart. The subject matter in the background section merely representsdifferent approaches, which in and of themselves may also be inventions.

Organizations and enterprises typically employ many different types ofsoftware and computing technologies to meet their computing needs.However, installing and maintaining software on an organization's owncomputer systems may involve one or more drawbacks. For example, whensoftware must be installed on computer systems within the organization,the installation process often requires significant time commitments,since organization personnel may need to separately access eachcomputer. Once installed, the maintenance of such software typicallyrequires significant additional resources. Each installation of thesoftware may need to be separately monitored, upgraded, and/ormaintained. Further, organization personnel may need to protect eachinstalled piece of software against viruses and other malevolent code.Given the difficulties in updating and maintaining software installed onmany different computer systems, it is common for software to becomeoutdated. Also, the organization will likely need to ensure that thevarious software programs installed on each computer system arecompatible. Compatibility problems are compounded by frequent upgrading,which may result in different versions of the same software being usedat different computer systems in the same organization.

Accordingly, organizations and enterprises increasingly prefer to useon-demand services accessible via the Internet rather than softwareinstalled on in-house computer systems. On-demand services, often termed“cloud computing” services, take advantage of increased network speedsand decreased network latency to provide shared resources, software, andinformation to computers and other devices upon request. Cloud computingtypically involves over-the-Internet provision of dynamically scalableand often virtualized resources. Technological details can be abstractedfrom the users, who no longer have need for expertise in, or controlover, the technology infrastructure “in the cloud” that supports them.

BRIEF SUMMARY

Disclosed are systems, methods, and apparatus for context-awaremessaging. In various implementations, a method for providing acontextual view for an information feed is provided. The method maycomprise hosting a conversation between two or more users, where theconversation generates text included in a conversation thread. Themethod may further comprise extracting information and a plurality ofentities from the generated text. The method may also comprise assigningone or more weights to each of the extracted plurality of entities basedon the contents of the conversation thread, where the one or moreweights provide a rank for each of the extracted plurality of entitiesin a search of at least one information feed. The method may furthercomprise searching the at least one information feed based on theweighted extracted plurality of entities to identify at least onerelevant information feed. The method may also comprise updating the atleast one relevant information feed with the information extracted fromthe conversation thread.

In some implementations, the conversation is hosted by an instantmessaging service and the at least one information feed is provided byan online social network. In various implementations, the one or moreweights are generated based on at least one of a static lookup table andcomputer-generated metrics related to the contents of the conversationthread. According to some implementations, the computer-generatedmetrics are generated based on at least one of a number of occurrencesof an entity within the conversation thread and a recency associatedwith the occurrence of the entity. An entity may be at least one of thegroup consisting of: a user name, a product, a company, an account, alocation, a project, and a connection event. In some implementations,updating the at least one relevant information feed comprises storinginformation extracted from the conversation thread in a feed data storeassociated with the at least one relevant information feed. In variousimplementations, the extracted information includes the text of theconversation thread and a plurality of context attributes associatedwith the text of the conversation thread. The method may furthercomprise normalizing and mapping the extracted plurality of entitiesfrom a first format to a second format. In some implementations, themethod further comprises providing one or more filters configured tofilter a presentation of the updated at least one relevant informationfeed based on the information extracted from the conversation thread.The method may further comprise refreshing a user interface of an onlinesocial network to render the updated at least one relevant informationfeed. In some implementations, the method further comprises receiving aselection from one of the two or more users, the selection selecting theat least one relevant information feed to be updated.

In various implementations, a non-transitory machine-readable mediumprovides, when executed by one or more processors, a contextual view foran information feed. The non-transitory machine-readable medium maycarry one or more sequences of instructions which, when executed by oneor more processors, cause the one or more processors to carry out thesteps of: hosting a conversation between two or more users, theconversation generating text included in a conversation thread;extracting information and a plurality of entities from the generatedtext; assigning one or more weights to each of the extracted pluralityof entities based on the contents of the conversation thread, the one ormore weights providing a rank for each of the extracted plurality ofentities in a search of at least one information feed; searching the atleast one information feed based on the weighted extracted plurality ofentities to identify at least one relevant information feed; andupdating the at least one relevant information feed with the informationextracted from the conversation thread.

In some implementations, a system provides a contextual view for aninformation feed. The system may comprise a processor. The system mayfurther comprise one or more stored sequences of instructions which,when executed by the processor, cause the processor to carry out thesteps of: hosting a conversation between two or more users, theconversation generating text included in a conversation thread;extracting information and a plurality of entities from the generatedtext; assigning one or more weights to each of the extracted pluralityof entities based on the contents of the conversation thread, the one ormore weights providing a rank for each of the extracted plurality ofentities in a search of at least one information feed; searching the atleast one information feed based on the weighted extracted plurality ofentities to identify at least one relevant information feed; andupdating the at least one relevant information feed with the informationextracted from the conversation thread.

Conventional methods may provide a user with a way to communicate withanother user via online communications. For example, a user may use aninstant messaging program to have a conversation with another user.However, conventional methods are limited because they do not provide auser with an interface to other systems and sources of information.Thus, the user is not provided with the ability to automaticallyidentify and retrieve other information related to the conversation fromother relevant sources. Thus, if a first user is communicating with asecond user about a case, the users may have to manually and separatelyaccess a separate system to access a file or record associated with thecase. In many situations, the users might not be able to access theassociated file at all. Furthermore, conventional methods do not provideusers with an interface between a communication tool, such as an instantmessaging service, and an online social network. Thus, if two users havea conversation using an instant messaging service, they cannot sharethat conversation or contextual information associated with theconversation in an information feed of the online social network.

In various implementations disclosed herein, contextual information maybe aggregated from various different systems and environments. Thecontextual information may be used to modify a presentation andfunctionality of a mode of communication. For example, a communicationtool that implements the mode of communication, such as an instantmessaging tool, may be modified based on contextual information. Thus,the user interface of the communication tool may be modified to includeadditional information related to a conversation thread based on auser's context. Context information may also be used to modifyinformation stored in an information feed and modify a presentation ofthe information feed in an online social network. Thus, according tosome implementations, context attributes identified and retrieved basedon the contents of the conversation thread may be pushed to theinformation feed. The conversation thread and contextual information maythen be rendered as part of the information feed and accessible to otherentities in the online social network.

In an example of a use case, a customer may contact a salesperson with aquestion about a product. The salesperson may have previously interactedwith the customer when the salesperson traveled to the customer'sbusiness organization to setup a software application. The customermight need follow up support and may have contacted the salesperson viaan instant messaging service, such as Chatter® Instant Messenger. Acontext attribute interface may analyze the content of theirconversation to identify and retrieve relevant contextual information.Thus, based on the entities involved in the conversation and thesoftware application mentioned in the conversation, the contextattribute interface may retrieve knowledge database articles and productinformation related to the software application. Moreover, the contextattribute interface may retrieve information about the salesperson'sprevious visit to the customer. The context attribute interface mayprovide this information to the salesperson at the user interface of thecommunication tool. Thus, the context attribute interface may retrieveand present information from various different sources, such as acustomer relationship management (CRM) database and knowledge databases.Moreover, the context attribute interface may use the content of theconversation to identify relevant information feeds and feed posts in anonline social network that the salesperson uses. The context attributeinterface may post the contents of the conversation in relevantinformation feeds so that other salespeople that subscribe to the feedmay now see and access the conversation thread.

Any of the above embodiments may be used alone or together with oneanother in any combination. The one or more implementations encompassedwithin this specification may also include embodiments that are onlypartially mentioned or alluded to or are not mentioned or alluded to atall in this brief summary or in the abstract. Although variousembodiments may have been motivated by various deficiencies with theprior art, which may be discussed or alluded to in one or more places inthe specification, the embodiments do not necessarily address any ofthese deficiencies. In other words, different embodiments may addressdifferent deficiencies that may be discussed in the specification. Someembodiments may only partially address some deficiencies or just onedeficiency that may be discussed in the specification, and someembodiments may not address any of these deficiencies.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following drawings like reference numbers are used to refer tolike elements. Although the following figures depict various examples,the one or more implementations are not limited to the examples depictedin the figures.

FIG. 1 shows a diagram of various different types of context attributeswhich may be associated with a user of a context-aware messaging system,in accordance with some implementations.

FIG. 2 shows a block diagram of an example of an environment 10 in whichan on-demand database service can be used in accordance with someimplementations.

FIG. 3 shows a block diagram of an example of a system in whichcontextual attributes may be stored and used, in accordance with someimplementations.

FIG. 4 shows a block diagram of an example of a system in which acontextual information, such as context attributes, may be aggregatedand stored in a context data store, in accordance with someimplementations.

FIG. 5 shows a flowchart of an example of a method of extracting contextattributes from connection event data, performed in accordance with someimplementations.

FIG. 6 shows a flowchart of an example of a method of extracting contextattributes from one or more information feeds, performed in accordancewith some implementations.

FIG. 7 shows a flowchart of an example of a method of generating apresentation of a mode of communication based on context attributes,performed in accordance with some implementations.

FIG. 8 shows a flowchart of an example of a method of updating one ormore information feeds based on at least one conversation in acommunication tool, performed in accordance with some implementations.

FIG. 9 illustrates an example of an image of a user interface screenthat may be rendered based on scored context attributes, in accordancewith some implementations.

FIG. 10 illustrates another example of an image of a user interfacescreen that may be rendered based on scored context attributes, inaccordance with some implementations.

FIG. 11 illustrates an example of an image of a user interface screenthat may be used to update information stored in information feeds of asocial network based on information extracted from a communicationstool, in accordance with some implementations.

FIG. 12 illustrates an example of an image of feed posts that have beenupdated with information from a conversation thread, in accordance withsome implementations.

FIG. 13 illustrates an example of an image of a user interface screenthat may be used to update information stored in CRM database based oninformation extracted from a communications tool.

DETAILED DESCRIPTION

Systems and methods are provided for context-aware messaging. Examplesof systems, apparatus, and methods according to the disclosedimplementations are described in this section. These examples are beingprovided solely to add context and aid in the understanding of thedisclosed implementations. It will thus be apparent to one skilled inthe art that implementations may be practiced without some or all ofthese specific details. In other instances, certain process/methodoperations, also referred to herein as “blocks” or “steps,” have notbeen described in detail in order to avoid unnecessarily obscuringimplementations. Other applications are possible, such that thefollowing examples should not be taken as definitive or limiting eitherin scope or setting.

In the following detailed description, references are made to theaccompanying drawings, which form a part of the description and in whichare shown, by way of illustration, specific implementations. Althoughthese implementations are described in sufficient detail to enable oneskilled in the art to practice the disclosed implementations, it isunderstood that these examples are not limiting, such that otherimplementations may be used and changes may be made without departingfrom their spirit and scope. For example, the blocks of methods shownand described herein are not necessarily performed in the orderindicated. It should also be understood that the methods may includemore or fewer blocks than are indicated. In some implementations, blocksdescribed herein as separate blocks may be combined. Conversely, whatmay be described herein as a single block may be implemented in multipleblocks.

Various implementations described or referenced herein are directed todifferent methods, apparatus, systems, and computer program products fora context-aware messaging system that may interact with or include anonline social network, also referred to herein as a social networkingsystem or an enterprise social network. Feed items in an informationfeed may include information updates stored in an on-demand databaseservice environment. In some implementations, the disclosed methods,apparatus, systems, and computer program products may be configured ordesigned for use in a multi-tenant database environment.

In some implementations, an online social network may allow a user tofollow data objects in the form of records such as cases, accounts, oropportunities, in addition to following individual users and groups ofusers. One example of such an online social network is Chatter®,provided by Salesforce.com® of San Francisco, Calif. Such online socialnetworks can be implemented in various settings, including enterprisessuch as business organizations or groups within such an organization.For instance, Chatter® can be used by employee users of a businessorganization to communicate and collaborate with each other for variouspurposes.

The “following” of a record stored in a database, as described ingreater detail below, allows a user to track the progress of thatrecord. Updates to the record, also referred to herein as changes to therecord, can occur and be noted on an information feed such as the recordfeed or the news feed of a user subscribed to the record. With thedisclosed implementations, such record updates are often presented as anitem or entry in the feed. Such a feed item can include a single updateor a collection of individual updates. Information updates presented asfeed items in an information feed can include updates to a record, aswell as other types of updates such as user actions and events, asdescribed herein.

Examples of record updates include field changes in the record, as wellas the creation of the record itself Examples of other types ofinformation updates, which may or may not be linked with a particularrecord depending on the specific use of the information update, includemessages as described herein. Examples of such messages include postssuch as explicit text or characters submitted by a user, multimedia datasent between or among users (for instance, included in a post), statusupdates such as updates to a user's status or updates to the status of arecord, uploaded files, indications of a user's personal preferencessuch as “likes” and “dislikes,” and links to other data or records.

Information updates can also be group-related, e.g., a change to groupstatus information for a group of which the user is one of possiblyadditional members. A user following, e.g., subscribed to, a record iscapable of viewing record updates on the user's news feed, which canalso include the other various types of information updates describedabove. Any number of users can follow a record and thus view recordupdates in this fashion. Some records are publicly accessible, such thatany user can follow the record, while other records are private, forwhich appropriate security clearance/permissions are a prerequisite to auser following the record.

Online social networks are increasingly becoming a common way tofacilitate communication between individuals and groups of individuals,any of whom can be recognized as “users” of a social networking system.In many social networks, individuals may establish connections with oneother, which may be referred to as “friending” one another. Byestablishing such a connection, one user may be able to see informationgenerated by or associated with another user. For instance, a first usermay be able to see information posted by a second user to the firstuser's personal social network page. One implementation of such apersonal social network page is a user's profile page, for example, inthe form of a web page representing the user's profile. For example, apost submitted by the second user about the first user can be presentedon the first user's profile feed, also referred to herein as the user's“wall,” which can be displayed on the first user's profile page.

In some implementations, an information feed in the context of a socialnetwork may be a collection of information selected from the socialnetwork for presentation in a user interface. The information presentedin the information feed may include posts to a user's wall or any othertype of information accessible within the social network. A feed itemcan include various types of data including character-based data, audiodata, video data, or combinations of these. For instance, a post caninclude text in combination with a JPEG image or animated image.

Feed items in information feeds such as a user's news feed may includemessages, which can take the form of: posts comprisingtextual/character-based inputs such as words, phrases, statements,questions, emotional expressions, symbols, leetspeak, or combinations ofthese; responses to posts, also referred to herein as “comments”, suchas words, phrases, statements, answers, questions, reactionary emotionalexpressions, or combinations of these; indications of personalpreferences which can be submitted as responses to posts or comments;status updates; and hyperlinks. In other examples, messages can be inthe form of file uploads, such as presentations, documents, multimediafiles, and the like.

In some implementations, a news feed may be specific to an individualuser, a group of users, or a data object (e.g., a file, document, Webpage, or a collection of documents, files, or Web pages). For instance,a group of users on a social network may publish a news feed. Members ofthe group and the larger social network may view and post to the groupnews feed in accordance with a permissions configuration for the newsfeed and the group.

In some implementations, when data such as posts or comments input fromone or more users are published to an information feed for a particularuser, group, object, or other construct within a social network, ane-mail notification or other type of notification (e.g., text message)may be transmitted to all users following the user, group, or object inaddition to the posting of the published data as a feed item in one ormore feeds, such as a news feed or a record feed. In some socialnetworks, the occurrence of such a notification is limited to the firstinstance of a published input, which may form part of a largerconversation. For instance, a notification may be transmitted for aninitial post, but neither for comments on the post nor for follow-upposts related to the initial post. In some other implementations,notifications are transmitted for all such published inputs.

These and other implementations described and reference herein may beembodied in various types of hardware, software, firmware, ofcombinations of these. For example, some techniques disclosed herein maybe implemented, at least in part, by machine-readable media that includeprogram instructions, state information, etc., for performing variousservices and operations described herein. Examples of programinstructions include both machine code, such as produced by a compiler,and files containing higher-level code that may be executed by acomputing device such as a server or other data processing apparatususing an interpreter. Examples of machine-readable media include, butare not limited to, magnetic media such as hard disks, floppy disks, andmagnetic tape; optical media such as CD-ROM disks; magneto-opticalmedia; and hardware devices that are specially configured to storeprogram instructions, such as read-only memory devices (“ROM”) andrandom access memory (“RAM”) devices. These and other features of thedisclosed implementations will be described in more detail below withreference to the associated drawings.

The term “multi-tenant database system” can refer to those systems inwhich various elements of hardware and software of a database system maybe shared by one or more customers. For example, a given applicationserver may simultaneously process requests for a great number ofcustomers, and a given database table may store rows for a potentiallymuch greater number of customers. The term “query plan” generally refersto one or more operations used to access information in a databasesystem.

A “user profile” or “user's profile” is generally configured to storeand maintain data about the user of the database system. The data caninclude general information, such as title, phone number, a photo, abiographical summary, and a status (e.g., text describing what the useris currently doing). As mentioned below, the data can include messagescreated by other users. Where there are multiple tenants, a user istypically associated with a particular tenant. For example, a user couldbe a salesperson of a company, which is a tenant of the database systemthat provides a database service.

The term “record” generally refers to a data entity, such as an instanceof a data object created by a user of the database service, for example,about a particular (actual or potential) business relationship orproject. The data object can have a data structure defined by thedatabase service (a standard object) or defined by a subscriber (customobject). For example, a record can be for a business partner orpotential business partner (e.g., a client, vendor, distributor, etc.)of the user, and can include an entire company, subsidiaries, orcontacts at the company. As another example, a record can be a projectthat the user is working on, such as an opportunity (e.g., a possiblesale) with an existing partner, or a project that the user is trying toget. In one implementation of a multi-tenant database, each record forthe tenants has a unique identifier stored in a common table. A recordhas data fields that are defined by the structure of the object (e.g.,fields of certain data types and purposes). A record can also havecustom fields defined by a user. A field can be another record orinclude links thereto, thereby providing a parent-child relationshipbetween the records.

The terms “information feed” and “feed” are used interchangeably hereinand generally refer to a combination (e.g., a list) of feed items orentries with various types of information and data. Such feed items canbe stored and maintained in one or more database tables, e.g., as rowsin the table(s), that can be accessed to retrieve relevant informationto be presented as part of a displayed feed. The term “feed item” (orfeed element) refers to an item of information, which can be presentedin the feed such as a post published by a user. Feed items ofinformation about a user can be presented in a user's profile feed ofthe database, while feed items of information about a record can bepresented in a record feed in the database, by way of example. A profilefeed and a record feed are examples of different information feeds. Asecond user following a first user or record can receive the feed itemsassociated with the first user and the record for display in the seconduser's news feed, which is another type of information feed. In someimplementations, the feed items from any number of followed users andrecords can be combined into a single information feed of a particularuser.

As examples, a feed item can be a message, such as a user-generated postof text data, and a feed tracked update to a record or profile, such asa change to a field of the record. A feed can be a combination ofmessages and feed tracked updates. Messages include text created by auser, and may include other data as well. Examples of messages includeposts, user status updates, and comments. Messages can be created for auser's profile or for a record. Posts can be created by various users,potentially any user, although some restrictions can be applied. As anexample, posts can be made to a wall section of a user's profile page(which can include a number of recent posts) or a section of a recordthat includes multiple posts. The posts can be organized inchronological order when displayed in a graphical user interface (GUI),for instance, on the user's profile page, as part of the user's profilefeed. In contrast to a post, a user status update changes a status of auser and can be made by that user or an administrator. Other similarsections of a user's profile can also include an “About” section. Arecord can also have a status, the update of which can be provided by anowner of the record or other users having suitable write accesspermissions to the record. The owner can be a single user, multipleusers, or a group. In one implementation, there is only one status for arecord.

In one implementation, a comment can be made on any feed item. Inanother implementation, comments are organized as a list explicitly tiedto a particular feed tracked update, post, or status update. In thisimplementation, comments may not be listed in the first layer (in ahierarchal sense) of feed items, but listed as a second layer branchingfrom a particular first layer feed item.

A “feed tracked update,” also referred to herein as a “feed update,” isone type of information update and generally refers to data representingan event. A feed tracked update can include text generated by thedatabase system in response to the event, to be provided as one or morefeed items for possible inclusion in one or more feeds. In oneimplementation, the data can initially be stored, and then the databasesystem can later use the data to create text for describing the event.Both the data and/or the text can be a feed tracked update, as usedherein. In various implementations, an event can be an update of arecord and/or can be triggered by a specific action by a user. Whichactions trigger an event can be configurable. Which events have feedtracked updates created and which feed updates are sent to which userscan also be configurable. Messages and feed updates can be stored as afield or child object of the record. For example, the feed can be storedas a child object of the record.

A “group” is generally a collection of users. In some implementations,the group may be defined as users with a same or similar attribute, orby membership. In one implementation, a “group feed” includes any feeditem about any user in a group. In another implementation, the groupfeed includes feed items that are about the group as a whole. In oneimplementation, the feed items for a group are only posts and comments.

An “entity feed” or “record feed” generally refers to a feed of feeditems about a particular record in the database, such as feed trackedupdates about changes to the record and posts made by users about therecord. An entity feed can be composed of any type of feed item. Such afeed can be displayed on a page such as a web page associated with therecord, e.g., a home page of the record. As used herein, a “profilefeed” is a feed of feed items about a particular user. In oneimplementation, the feed items for a profile feed are posts and commentsthat other users make about or send to the particular user, and statusupdates made by the particular user. Such a profile feed can bedisplayed on a page associated with the particular user.

In another implementation, feed items in a profile feed could includeposts made by the particular user and feed tracked updates initiatedbased on actions of the particular user.

In various implementations, systems, apparatus, and methods are providedfor context-aware messaging. Contextual information that relates to auser's current context may be aggregated from various different systemsand environments or determined based on actions taken by the user orother entities. Contextual attributes included in the contextualinformation may be integrated into on-demand services that the usersubscribes to, such as an instant messaging service and an online socialnetwork. In some implementations, a context attribute is data orinformation that describes a user's interactions with or relation toother entities in an on-demand service environment. Contextualattributes may be a result of on-demand products or services being usedto interact with other entities, such as other users of an on-demandservice or online social network. Contextual attributes may bedetermined, gathered, and/or used by various systems and sub-systems,such as Text Analytics or a Chatter® group administrative setup.

FIG. 1 shows a diagram of various different types of context attributeswhich may be associated with a user of a context-aware messaging system,in accordance with some implementations. As shown in FIG. 1, a user maybe a salesperson who subscribes to services provided by an on-demandservice provider, such as Salesforce.com®. In some implementations, acontext attribute interface and a context data store may be provided aspart of the services provided by the on-demand service provider. Thecontext attribute interface and a context data store may retrieve andstore contextual information and context attributes from variousdifferent sources and integrate the contextual information into existingservices that the salesperson already subscribes to. For example, thesalesperson may interact with a customer, who may be part of aparticular organization that is situated at a particular location. Thecontext attribute interface and the context data store may retrievecontext attributes identifying the customer's name, a product that thecustomer bought, and an account associated with the customer'sorganization. Such information may be retrieved from a multi-tenantdatabase system which may provide a customer relationship management(CRM) database.

The context attribute interface and the context data store may retrievecontextual information from other sources as well, such as a log orhistory file detailing the salesperson's interactions with an enterpriseapplication, and various data objects within the enterprise application.Furthermore, the context attribute interface and the context data storemay retrieve contextual information from an event database that storesconnection events describing connections and interactions between thesalesperson and other entities, such as the customer. Further still, thecontext attribute interface and the context data store may retrievecontextual information from a group of users that may be part of anonline social network, such as Chatter® provided by Salesforce.com®.Thus, context information may be retrieved from multiple sourcesresiding in multiple different database systems.

In some implementations, context information is used to modify apresentation and functionality of a mode of communication. Thus, acommunication tool that implements the mode of communication, such as aninstant messaging service that provides instant messaging capabilities,may be modified based on a user's current context. Context attributesassociated with a conversation thread may be identified and retrieved.The context attributes may be scored and ranked based on the user'scontext. A user interface of the communication tool may be modified toinclude the most relevant context attributes. In this way, the userinterface of the communications tool may be modified to includeadditional information related to a conversation thread based on theuser's context.

Context information may also be used to modify information stored in aninformation feed and modify a presentation of the information feed in anonline social network. In some implementations, context attributesidentified and retrieved based on the contents of a conversation threadmay be pushed to an information feed of an online social network. Thecontext attributes may be used to identify relevant information feedsand feed posts. The conversation thread and the context attributes maybe stored as a data object associated with the identified informationfeeds and feed posts. The data object may be rendered and presented aspart of the information feed, thus making the conversation thread andcontext attributes available to any entity subscribing to the feed.Thus, contextual information may be retrieved and aggregated fromvarious different sources, and integrated into an online social networkthat may be provided as an on-demand database service.

FIG. 2 shows a block diagram of an example of an environment 10 in whichan on-demand database service can be used in accordance with someimplementations. Environment 10 may include user systems 12, network 14,database system 16, processor system 17, application platform 18,network interface 20, tenant data storage 22, system data storage 24,program code 26, and process space 28. In other implementations,environment 10 may not have all of these components and/or may haveother components instead of, or in addition to, those listed above.

Environment 10 is an environment in which an on-demand database serviceexists. User system 12 may be any machine or system that is used by auser to access a database system 16. For example, any of user systems 12can be a handheld computing device, a mobile phone, a laptop computer, awork station, and/or a network of such computing devices. As illustratedin FIG. 2 user systems 12 might interact via a network 14 with anon-demand database service, which is implemented in the example of FIG.2 as database system 16.

An on-demand database service, such as system 16, is a database systemthat is made available to outside users, who do not need to necessarilybe concerned with building and/or maintaining the database system.Instead, the database system may be available for their use when theusers need the database system, i.e., on the demand of the users. Someon-demand database services may store information from one or moretenants into tables of a common database image to form a multi-tenantdatabase system (MTS). A database image may include one or more databaseobjects. A relational database management system (RDBMS) or theequivalent may execute storage and retrieval of information against thedatabase object(s). Application platform 18 may be a framework thatallows the applications of system 16 to run, such as the hardware and/orsoftware, e.g., the operating system. In some implementations,application platform 18 enables creation, managing and executing one ormore applications developed by the provider of the on-demand databaseservice, users accessing the on-demand database service via user systems12, or third party application developers accessing the on-demanddatabase service via user systems 12.

The users of user systems 12 may differ in their respective capacities,and the capacity of a particular user system 12 might be entirelydetermined by permissions (permission levels) for the current user. Forexample, where a salesperson is using a particular user system 12 tointeract with system 16, that user system has the capacities allotted tothat salesperson. However, while an administrator is using that usersystem to interact with system 16, that user system has the capacitiesallotted to that administrator. In systems with a hierarchical rolemodel, users at one permission level may have access to applications,data, and database information accessible by a lower permission leveluser, but may not have access to certain applications, databaseinformation, and data accessible by a user at a higher permission level.Thus, different users will have different capabilities with regard toaccessing and modifying application and database information, dependingon a user's security or permission level, also called authorization.

Network 14 is any network or combination of networks of devices thatcommunicate with one another. For example, network 14 can be any one orany combination of a LAN (local area network), WAN (wide area network),telephone network, wireless network, point-to-point network, starnetwork, token ring network, hub network, or other appropriateconfiguration. Network 14 can include a TCP/IP (Transfer ControlProtocol and Internet Protocol) network, such as the global internetworkof networks often referred to as the “Internet” with a capital “I.” TheInternet will be used in many of the examples herein. However, it shouldbe understood that the networks that the present implementations mightuse are not so limited, although TCP/IP is a frequently implementedprotocol.

User systems 12 might communicate with system 16 using TCP/IP and, at ahigher network level, use other common Internet protocols tocommunicate, such as HTTP, FTP, AFS, WAP, etc. In an example where HTTPis used, user system 12 might include an HTTP client commonly referredto as a “browser” for sending and receiving HTTP signals to and from anHTTP server at system 16. Such an HTTP server might be implemented asthe sole network interface 20 between system 16 and network 14, butother techniques might be used as well or instead. In someimplementations, the network interface 20 between system 16 and network14 includes load sharing functionality, such as round-robin HTTP requestdistributors to balance loads and distribute incoming HTTP requestsevenly over a plurality of servers. At least for users accessing system16, each of the plurality of servers has access to the MTS' data;however, other alternative configurations may be used instead.

In one implementation, system 16, shown in FIG. 2, implements aweb-based customer relationship management (CRM) system. For example, inone implementation, system 16 includes application servers configured toimplement and execute CRM software applications as well as providerelated data, code, forms, web pages and other information to and fromuser systems 12 and to store to, and retrieve from, a database systemrelated data, objects, and Webpage content. With a multi-tenant system,data for multiple tenants may be stored in the same physical databaseobject in tenant data storage 22, however, tenant data typically isarranged in the storage medium(s) of tenant data storage 22 so that dataof one tenant is kept logically separate from that of other tenants sothat one tenant does not have access to another tenant's data, unlesssuch data is expressly shared. In certain implementations, system 16implements applications other than, or in addition to, a CRMapplication. For example, system 16 may provide tenant access tomultiple hosted (standard and custom) applications, including a CRMapplication. User (or third party developer) applications, which may ormay not include CRM, may be supported by the application platform 18,which manages creation, storage of the applications into one or moredatabase objects and executing of the applications in a virtual machinein the process space of the system 16.

One arrangement for elements of system 16 is shown in FIG. 2, includinga network interface 20, application platform 18, tenant data storage 22for tenant data 23, system data storage 24 for system data 25 accessibleto system 16 and possibly multiple tenants, program code 26 forimplementing various functions of system 16, and a process space 28 forexecuting MTS system processes and tenant-specific processes, such asrunning applications as part of an application hosting service.Additional processes that may execute on system 16 include databaseindexing processes.

Several elements in the system shown in FIG. 2 include conventional,well-known elements that are explained only briefly here. For example,each user system 12 could include a desktop personal computer,workstation, laptop, PDA, cell phone, or any wireless access protocol(WAP) enabled device or any other computing device capable ofinterfacing directly or indirectly to the Internet or other networkconnection. User system 12 typically runs an HTTP client, e.g., abrowsing program, such as Microsoft's Internet Explorer browser,Netscape's Navigator browser, Opera's browser, or a WAP-enabled browserin the case of a cell phone, PDA or other wireless device, or the like,allowing a user (e.g., subscriber of the multi-tenant database system)of user system 12 to access, process and view information, pages andapplications available to it from system 16 over network 14. Each usersystem 12 also typically includes one or more user interface devices,such as a keyboard, a mouse, trackball, touch pad, touch screen, pen orthe like, for interacting with a graphical user interface (GUI) providedby the browser on a display (e.g., a monitor screen, LCD display, etc.)of the computing device in conjunction with pages, forms, applicationsand other information provided by system 16 or other systems or servers.For example, the user interface device can be used to access data andapplications hosted by system 16, and to perform searches on storeddata, and otherwise allow a user to interact with various GUI pages thatmay be presented to a user. As discussed above, implementations aresuitable for use with the Internet, although other networks can be usedinstead of or in addition to the Internet, such as an intranet, anextranet, a virtual private network (VPN), a non-TCP/IP based network,any LAN or WAN or the like.

According to one implementation, each user system 12 and all of itscomponents are operator configurable using applications, such as abrowser, including computer code run using a central processing unitsuch as an Intel Pentium® processor or the like. Similarly, system 16(and additional instances of an MTS, where more than one is present) andall of its components might be operator configurable usingapplication(s) including computer code to run using processor system 17,which may be implemented to include a central processing unit, which mayinclude an Intel Pentium® processor or the like, and/or multipleprocessor units. A computer program product implementation includes anon-transitory machine-readable storage medium (media) havinginstructions stored thereon/in, which can be used to program a computerto perform any of the processes/methods of the implementations describedherein. Computer program code 26 for operating and configuring system 16to intercommunicate and to process web pages, applications and otherdata and media content as described herein is preferably downloadableand stored on a hard disk, but the entire program code, or portionsthereof, may also be stored in any other volatile or non-volatile memorymedium or device as is well known, such as a ROM or RAM, or provided onany media capable of storing program code, such as any type of rotatingmedia including floppy disks, optical discs, digital versatile disk(DVD), compact disk (CD), microdrive, and magneto-optical disks, andmagnetic or optical cards, nanosystems (including molecular memory ICs),or any type of media or device suitable for storing instructions and/ordata. Additionally, the entire program code, or portions thereof, may betransmitted and downloaded from a software source over a transmissionmedium, e.g., over the Internet, or from another server, as is wellknown, or transmitted over any other conventional network connection asis well known (e.g., extranet, VPN, LAN, etc.) using any communicationmedium and protocols (e.g., TCP/IP, HTTP, HTTPS, Ethernet, etc.) as arewell known. It will also be appreciated that computer code for thedisclosed implementations can be realized in any programming languagethat can be executed on a client system and/or server or server systemsuch as, for example, C, C++, HTML, any other markup language, Java™,JavaScript, ActiveX, any other scripting language, such as VBScript, andmany other programming languages as are well known may be used. (Java™is a trademark of Sun Microsystems, Inc.).

According to some implementations, each system 16 is configured toprovide web pages, forms, applications, data and media content to user(client) systems 12 to support the access by user systems 12 as tenantsof system 16. As such, system 16 provides security mechanisms to keepeach tenant's data separate unless the data is shared. If more than oneMTS is used, they may be located in close proximity to one another(e.g., in a server farm located in a single building or campus), or theymay be distributed at locations remote from one another (e.g., one ormore servers located in city A and one or more servers located in cityB). As used herein, each MTS could include one or more logically and/orphysically connected servers distributed locally or across one or moregeographic locations. Additionally, the term “server” is meant to referto a computing device or system, including processing hardware andprocess space(s), an associated storage system such as a memory deviceor database, and, in some instances, a database application (e.g.,OODBMS or RDBMS) as is well known in the art. It should also beunderstood that “server system” and “server” are often usedinterchangeably herein. Similarly, the database objects described hereincan be implemented as single databases, a distributed database, acollection of distributed databases, a database with redundant online oroffline backups or other redundancies, etc., and might include adistributed database or storage network and associated processingintelligence.

FIG. 3 shows a block diagram of an example of a system in whichcontextual attributes may be stored and used, in accordance with someimplementations. System 300 provides an interface that integratescontext information from various different social networks,collaborative environments, and modes of communication. Thus, contextinformation may be aggregated from many different database systems thatmay be used to provide different services and manage different useraccounts. System 300 may include context attribute interface 302,contextual view engine 304, feed post ranking engine 306, feed datastore interface 308, context attribute sources 310, context data store312, user products and services store 314, feed entity index 316, feeddata store 318, and messaging service 320.

Context attribute interface 302 may be an application program thatprocesses context information and manages interactions between varioussources of context information, one or more collaborative environmentsor social networks, and various different modes of communication, suchas messaging service 320. Collaborative networks and social networks mayrefer to online social networks such as Facebook®, Twitter®, andChatter®. Modes of communication may include an instant messagingservice, such as Chatter® Instant Messenger, or any other synchronous orasynchronous messaging system. Thus, context attribute interface 302 mayinclude one or more components that manage the storing, retrieval, andsharing of context attributes among various different components ofsystem 300. Context attribute interface 302 may be a softwareapplication implemented in one or more servers that include hardware andsoftware configured to execute instructions from a non-transitorycomputer readable medium. Context attribute interface 302 may be aspecific instance of a software application that has been instantiatedfor a user's account as part of an on-demand service that the usersubscribes to. Alternatively, context attribute interface 302 may be ashared resource that multiple users may access.

Context attribute interface 302 may include contextual view engine 304,which may generate a view or an appearance of a mode of communicationbased on various information, which may include context information. Insome implementations, the mode of communication is a messaging service,such as messaging service 320, which may be part of an on-demand servicethat a user subscribes to, such as Chatter® Instant Messenger. Contextattribute interface 302 may be communicatively coupled to messagingservice 320 and may be configured to retrieve information from and sendinformation to messaging service 320. Furthermore, contextual viewengine 304 may be configured to generate and render a user interface ofmessaging service 320 based on one or more context attributes retrievedfrom various context sources. Accordingly, contextual view engine 304may include a rendering engine capable of rendering various userinterface components that may be presented in and as part of a userinterface in a browser or dialog window. The rendering engine may beconfigured by a user or an administrator to configure how contextualview engine 304 renders context information. Contextual view engine 304may be coupled to various context attribute sources, as discussed ingreater detail with reference to FIG. 4. Contextual view engine 304 mayalso be coupled to one or more context data stores, such as context datastore 312. Thus, contextual view engine may have access to numeroussources of context attributes, and may incorporate relevant contextattributes into a presentation of one or more conversation threads inmessaging service 320.

Context attribute interface 302 may further include feed post rankingengine 306, which may score and rank information feeds and posts madewithin the information feeds based on context information andinformation parsed from one or more modes of communication used byusers. For example, feed post ranking engine 306 may extract informationfrom conversation threads, such as identifiers associated with entities,and use the extracted information to weight search terms which may beused to identify relevant information, such as feed posts. In this way,feed post ranking engine 306 may score and rank information retrievedfrom information feeds in one or more social networks based oninformation parsed from a conversation thread that a user had inmessaging system 320, which might not be associated with the socialnetworks, and might be part of a different system entirely.

Accordingly, feed post ranking engine 306 may include a parsing enginecapable of parsing text. Contextual view engine 304 may provide one ormore conversation threads to the parsing engine of feed post rankingengine 306. The parsing engine may be capable of performing one or moreoperations to extract text and identifiers associated with entitiesassociated with the received conversation thread, such as the entitieshaving the conversations or entities mentioned in the conversation.Alternatively, contextual view engine 304 may include a parsing engineand may parse information from conversation threads and send the parsedinformation to feed post ranking engine 306. Feed post ranking engine306 may be communicatively coupled to feed entity index 316, and may beconfigured to query a data store included in feed entity index 316 toidentify one or more data values based on search terms weighted by thepreviously described parsed information. Thus, feed post ranking engine306 may analyze information and terms parsed from messages andconversation threads to generate scores associated with the information.The scores may be determined based on one or more factors, such as afrequency of appearance or a relevance to a user. The scores mayrepresent a weight affixed to each term in a subsequent query.Accordingly, feed post ranking engine 306 may be configured to generateand conduct a database query in which search terms are weighted baseduser interactions in messaging system 320. Results of the query may beranked based on weights associated with the search terms underlying thequery. Thus, the results may identify feed information that has beenranked based on user interactions in a messaging system.

Context attribute interface 302 may further include feed data storeinterface 308, which may provide an interface to one or more feed datastores and may manage the modification or retrieval of information fromthe one or more feed data stores. Feed data store interface 308 may becoupled to feed post ranking engine 306 and may be configured to receivescoring and ranking information from feed post ranking engine 306. Feeddata store interface 308 may manage the scoring and ranking of datavalues stored in feed data store 318 based on the received scoring andranking information. In some implementations, a feed data store, such asfeed data store 318 stores information about information feeds in one ormore social networks or collaborative environments. The information maybe data related to posts in the feeds, such as feed topics andidentifiers of authors of posts. The information may also be metadataassociated with the feeds, such as a timestamp associated with thecreation of a feed or a post within the feed. Thus, feed data storeinterface 308 may manage the ranking and scoring of data related toinformation feeds that is stored in feed data store 318. The scoring andranking of information stored in feed data store 318 may be appliedglobally, in a manner specific to a user, or in a manner specific to agroup of users. Furthermore, feed data store interface 308 may managethe updating of data stored in feed data store 318 when informationfeeds are updated based on information parsed from one or moreconversation threads.

Context attribute sources 310 may be one or more sources of contextinformation. As similarly set forth above with reference to FIG. 1,context attribute sources 310 may refer to various sources of contextinformation which may be reside in different systems associated withdifferent groups of users. For example, context attribute sources mayinclude a connection database that stores physical interaction data,external knowledge databases, a user's history of actions, a CRMdatabase, and other applications or online services, such as an emailapplication or a calendaring application.

Context data store 312 may store retrieved context information. Thus,context data store may include one or more storage volumes that storecontext attributes associated with one or more users. Context data store312 may be accessible by several users and may provide a centralizedrepository for context information for several users. Alternatively,context data store 312 may be specific to a particular user and providedas part of an on-demand service that the user subscribes to. Asdiscussed in greater detail with reference to FIG. 4, context data store312 may be coupled to context attribute sources 310, and may retrieveand aggregate information directly from context attribute sources 310.Context data store 312 may also be coupled to contextual view engine 304and may provide context information and context attributes to contextualview engine 304 when requested.

User products and services store 314 may store information related toservices and products that a user subscribes to. For example, a user maysubscribe to one or more one-demand services provided by an on-demandservice provider. As part of the subscription process, the user may havecreated an account in which the user provides various information, suchas a username and other biographical information. Moreover, the user mayalso have information associated with the user's account, such as thename of an organization that that the user belongs to. Thus, informationretrieved from and associated with a user's profile may be stored inuser products and services store 314 and provided to context data store312 as context attributes.

Feed entity index store 316 may store one or more indexes generatedbased on information associated with a collaborative environment orsocial network. Feed entity index store 316 may generate and storeindexes which may be made available to feed post ranking engine 306,thus enabling feed post ranking engine 306 to search, score, and rankinformation from various information feeds stored in feed data store318. Accordingly, feed entity index store 316 may include a parsingengine configured to retrieve and parse information from feed data store318. The parsing engine may be configured to analyze one or more datastructures used to store feed information, such as feed posts, andextract one or more data values, such as names and unique identifiersfor entities associated with the feed information, such as a person ororganization that posted a feed post or was mentioned in a feed post.Feed entity index store 316 may generate and store one or more indexesbased on the extracted information. The indexes provide the feed postranking engine 306 with an organized representation of relevant feedinformation that may be searched quickly and efficiently.

FIG. 4 shows a block diagram of an example of a system in which acontextual information, such as context attributes, may be aggregatedand stored in a context data store, in accordance with someimplementations. Thus, FIG. 4 provides additional detail regarding howcontext attributes may be stored in a context data store. Accordingly,system 400 may include context data store 402, user products andservices store 404, and context attribute sources 406, which may includephysical connection events 408, group contextual metadata 410,enterprise application interaction events 412, and external sources 414.

As similarly discussed with reference to FIG. 3, context data store 402may include one or more storage volumes that store context attributesassociated with one or more users. Context data store 402 may beaccessible by on-demand services subscribed to by one or more users. Forexample, a user may subscribe to services such as an online socialnetwork and an instant messaging service, which may both have access tocontext data store 402. In some implementations, context data store 402may passively receive information that is pushed from context attributesources 406. Alternatively, context data store 402 may actively pollcontext attribute sources 406 to retrieve context attributes. Thus,context data store 402 may broadcast a request for context dataattributes to context attribute sources 406. It will be appreciated thatcontext data store 402 may perform some combination of both passivelyreceiving and actively retrieving information from context attributesources 406.

Context attribute sources 406 may refer to any number of sources ofinformation that may include context attributes. Context attributesources 406 may be located in the same network, or even same database ascontext data store 402. Context attribute sources 406 may be located ina separate network, and may provide information to context data store402 via the Internet using a web communications protocol.

Furthermore, context attribute sources 406 may include physicalconnection events 408 which may determined based on physical andwireless interactions between users or between users and objects. Forexample, the frequency of interaction between users can be used tomeasure the interaction strength of their relationship. In someimplementations, actions external to the online social network can beused to affect the interaction strength of users in an online socialnetwork.

Interaction strength information can be shared to the extent allowed bysettings. All social network users, or only those users who follow thefirst user, or only the first user can view the interaction strength onfirst user's profile page. Interaction strength can be based on metrics,such as the number of interactions within a defined time period (i.e.,frequency), the length of interaction, and the like. This interactionstrength calculation can consider interactions outside of the onlinesocial network, such as interactions observed with a CRM system. A firstuser's interactions with a second user recorded in the CRM system can beprovided to the social network and used to determine interactionstrength. In yet another implementation, interaction strength can alsobe based upon multiple social network interactions.

Physical interactions are captured based on wireless interactionsbetween mobile communication devices of two users. Use cases forpeer-to-peer communication between the respective mobile devices andsimultaneous interaction with a shared access point are described. Theseuse cases have in common physical proximity of users. The proximity ofmobile communication devices is used as a proxy for user interaction orat least for shared user experiences due to physical proximity.

Scheduled physical interactions are captured from calendar entries,event subscriptions, sign-ins and the like that place two users at thesame event. The scheduled physical interactions may be analyzed when theuser's respective privacy settings allow. Analysis of schedule physicalinteractions may be triggered by another interaction event, therebyreducing the potential intrusiveness of analyzing calendars.

Wireless communication interactions outside the social network can bemonitored using observer software residing on respective mobilecommunication devices. The observer software can monitor video, audioand text communications channels that are out of band from the socialnetwork.

In each of these use cases, connection events such as physicalconnection event, calendar connection event or wireless connection eventcan be created and stored in a database. A physical connection event canbe triggered by reception of a user identity token. The receiving devicecan record the duration and strength of the signal that broadcasted theuser identity token. It also can record the number of token broadcastsreceived and optionally their timing or continuity. Similarly, acalendar connection event is a memory update caused by a find or matchof calendar related electronic records of two users indicating theirco-attendance at an event. Likewise, a wireless connection event isregistered at a server when two users communicate with each otheroutside the social network using their respective wireless devices.

Moreover, the connection events can be processed to determineconnectedness scores for pairs of users. Connectedness scores can bemade available to users for their own connections and to permittedviewers.

In another example, context attribute sources 406 may include groupcontextual metadata 410. As previously discussed, a user may subscribeto an on-demand service that provides an online social network, such asChatter®, that may be part of a collaborative environment. The user maybelong to, subscribe to, or follow one or more groups of users on theonline social network. The on-demand service provider may store andmaintain various metadata associated with groups of users that use theonline social network. The metadata may be stored in a data store, suchas feed data store 318. The metadata may include data such as a numberof users in a group, identifiers of users who belong to the group, andtimestamp data associated with feed posts made within the group. Thus,group metadata may be retrieved from a feed data store and stored incontext data store 402 as context attributes.

In yet another example, context attribute sources 406 may includeenterprise application interaction events 412, which may be eventsassociated with one or more entities interacting with an enterpriseapplication. Thus, enterprise application interaction events 412 mayinclude one or more events generated by a user using an enterpriseapplication. For example, a user may access or modify one or more datavalues in a customer relationship management (CRM) database that isoperated and maintained as part of an enterprise application, such as aService Cloud® console provided by Salesforce.com®. The user actionsmade when interacting with the CRM database may be monitored and logged,thus storing a history of actions taken by a user. Furthermore, inaddition to storing actions taken by the user, data associated with theactions may be stored, such as identifiers associated with the dataobjects that were accessed or modified and data associated with thoseobjects, such as other users or organizations that the data objectsbelongs to. For example, if the user modifies an attribute, such as abusiness address of a contact stored in the CRM database, a log may bekept of the modification. The log may store one or more identifiersidentifying the action taken, a unique identifier for the contact forwhich a business address was modified, an organization that the contactbelongs to, and various associated metadata, such as a timestampindicating when the modification was made. This information may belogged and stored by the on-demand service provider, and provided tocontext data store 402 when requested. Each of the data values providedto context data store 402 may be stored and analyzed as contextattributes.

In another example, context attribute sources 406 may include externalsources 412. External sources may be any sources of contextualinformation that are located in or provided by networks, clouds,databases, or service providers that do not have unimpeded access to theonline social network associated with context data store 402. Forexample, a user may subscribe to an online social network such asChatter®. Chatter® may also provide the user with Chatter® InstantMessenger. In this instance, both the online social network andmessaging service are provided by the same service provider,Salesforce.com®. Thus, both the online social network and messagingservice may be tied to the same user account and have the ability tofreely share information with each other. However, an external source,such as an email application provided by a third party, would not beable to freely share information because it does not have the requisitelevel of access to the user's account. Thus, an application programinterface (API) may be provided that allows context data store 402 toaccess the user's email account, crawl email messages stored in theuser's account, parse information from the email messages, and identifyand retrieve contextual information from the email account, such ascontact names, message topics, and associated metadata. It will beappreciated that external sources may refer to other externalapplications, such as a calendaring application.

As similarly discussed with reference to FIG. 3, context data store 402may also retrieve information from user products and services store 404,which may include information related to services and products that auser subscribes to, such as account information, a username, otherbiographical information, and the identity of an organization that thatthe user belongs to.

FIG. 5 shows a flowchart of an example of a method of extracting contextattributes from connection event data, performed in accordance with someimplementations. A detailed description of examples of identifyingconnection events is discussed in commonly owned, co-pending U.S. patentapplication Ser. No. 13/743,895, entitled SYSTEMS AND METHODS FORMAPPING RELEVANT PERSONAL CONNECTIONS, by Parker Harris et al., filedJan. 17, 2013, which is incorporated herein by reference. Connectionevent context attribute extraction method 500 may extract contextattribute data relating to physical interactions between a user and oneor more other entities. The extracted context attributes may be storedin a context data store and may be used to provide context to one ormore other modes of communication associated with the user, such as aninstant messaging service. Furthermore, the extracted context attributesmay be used to provide context to one or more social networks orcollaborative environments by incorporating the extracted informationinto information feeds and using the extracted information to modify apresentation of the information feeds.

Accordingly, at step 502, a connection event database may be searched toidentify and rank physical connections based on a user's context. Aspreviously discussed, physical interactions between one or moreentities, such as a salesperson and a customer, may be inferred based onvarious indicators, such as a physical proximity and an amount of timespent within that physical proximity. Once determined, the physicalinteractions, and metadata associated with the physical interactions,may be stored in a connection event database. Thus, the connection eventdatabase may store connection information that identifies and describesconnections between various entities and a user. The connection eventdatabase may be searched to identify connection events that may berelevant to or provide information regarding a user's current context.Thus, the connection event database may be searched based on one or morealready identified context attributes to identify and retrieveadditional context attributes associated with connection event data.Moreover, a ranked list of connection event data may be generated byscoring and ranking the returned connection event data based on thealready determined context attributes that form the basis of the query.

For example, a context attribute interface may search the connectionevent database to identify connection events that may be relevant to auser's current context. In this example, a user, such as a salesperson,may be engaged in an instant message-based conversation with a customer.The context attribute interface may have parsed context attributes fromthe message thread, such as an identity of the salesperson, an identityof the customer, and a topic of the conversation. In this example, theconversation may be about technical support or follow up support for aparticular product that the salesperson sold to the customer. Thecontext attribute interface may query the connection event databasebased on identifiers associated with the salesperson, customer, andproduct. The query may return two connection events in which thesalesperson traveled to the customer's location. A first connectionevent may have been generated when the salesperson went to the customerto provide the product to the customer. For example, the salesperson mayhave installed and configured a software package for the customer. Thesecond connection event may have been generated based on a follow upvisit to update the software package. Both connection events and theirassociated data may be retrieved. Furthermore, they may be scored andranked. For example, the second connection event may be ranked higherbecause it occurred more recently, or because the current message threadis related to the most recent version of the software, which wasinstalled during the follow up visit that generated the secondconnection event.

At step 504, information associated with the connection events may beparsed to identify and extract entities relevant to the connectionevents. Thus, a parsing engine may be used to search the informationretrieved from the connection event database, identify identifiersassociated with entities mentioned in or associated with the connectionevents, and extract the identifiers associated with the relevantentities. For example, the connection event database may storeconnection events in a particular data structure that may include one ormore data fields configured to store one or more types of data. Thus,the data structure may include a data field configured to store a uniqueidentifier associated with an entity that generated the connectionevent, such as the salesperson. The data structure may further include adata field configured to store a unique identifier associated with anentity that was interacted with, such as the customer. Upon identifyinga connection event as relevant to a user's context, the parsing enginemay extract the unique identifiers from the data fields. Other contextattributes may be parsed and extracted as well, the product at issue,and a company associated with the customer. It will be appreciated thatthe process of extraction may include copying the extracted informationfrom the information that was retrieved from a query into a separatedata structure dedicated to storing a particular type of data orinformation.

At step 506, entities may be parsed and extracted from one or morecalendar events associated with a user. As set forth above, calendarevents may be determined based on scheduled physical interactions storedin a user's calendar. Thus, a context interface application may accessan application program that manages the user's calendar and may querythe calendar for scheduled events. In some implementations, the contextinterface application and the calendar application may be linked to thesame user account such that the context interface application mayautomatically access the user's calendar and extract calendar events.Alternatively, the context interface application and the calendarapplication may be linked to separate accounts, and the user may beprompted to provide access to the calendar application. Once providedaccess, the context interface application may query a data store thatstores the calendar events. As similarly set forth above, contextattributes extracted from the conversation thread may be used toidentify, score, and rank calendar events and context attributesincluded in the calendar events. Thus, a meeting or appointment that asalesperson has scheduled with a customer that the salesperson iscurrently conversing with may be identified, retrieved, and scored andranked as highly relevant.

At step 508, event location related context attributes may be extractedbased on a user's context. Thus, the context application interface mayanalyze the retrieved information to extract locations and locationattributes associated with the connection information. As similarlydiscussed above, the connection information may be stored in aparticular data structure that includes data fields dedicated to storingparticular types of data. Thus, the data structures may include datafields dedicated to storing a geographical, physical, or temporallocation associated with the connection event. For example, if aphysical connection was recorded for an on-site visit in which asalesperson visited a customer at his or her workplace, the location ofthe workplace, such as a business address, may be stored as a locationattribute in the data structure that stores the connection event. Suchlocation attributes may be extracted and stored in a separate datastructure.

At step 510, the extracted context attributes and entities may benormalized and mapped to a format or data structure that may be storedin a context data store. Thus, mapping and normalizing the extractedcontext attributes may convert the context attributes from multipledifferent formats used by multiple heterogeneous sources into a singleuniform format used by the context data store. Moreover, one or morecontext attributes may be associated with or inferred based on othercontext attributes. In some implementations, context attributes, such asproducts and services not explicitly included in connection event data,may be inferred based on a relationship between an interaction event andits location. For example, CRM sales records could contain one or moreattributes, such as GEO location attributes associated with a productdeployed at customer sites. These location attributes could becorrelated with locations logged in physical interaction events. Thus, alocation associated with a physical interaction event may be used toidentify a CRM record, such as a sales record, that shares the samelocation. The sales record may include context attributes such asproducts and services associated with the sale. The products andservices context attributes may be retrieved and associated with thephysical interaction events. The association of the products or serviceswith the physical interaction event may be verified by gatheringinformation from a salesperson as part of a routine sales businessprocess or physical interaction event logging process. In someimplementations, the context data store stores context attributes in adata structure having data fields dedicated to storing particular typesof context attributes. For example, the data structure may have datafields configured to store an identifier for a first entity, anidentifier for a second entity, and a location attribute. As set forthabove, the process of extraction may involve identifying one or moredata values in information that resulted from a query, and copying andstoring the identified data values into an intermediary data structure.The data values stored in the intermediary data structures may be mappedto data structures that have the same structure as data stored in thecontext data store.

For example, context attributes may be retrieved from a connectionevents database, which may include data pertaining to physicalconnections that result from a salesperson visiting different customersat the customers' respective places of business. Each of the customersmay be a part of a large organization and may have associated contextattributes, such as products and services that the customers havepurchased or subscribed to. The products and services for differentcustomers may be stored in the connection events database according todifferent formats depending on a region or company division. Forexample, a first geographical region or division may store informationabout products and services according to a first format, while a secondgeographical region or division may store information about products andservices according to a second format. The information about theproducts and services may be parsed and extracted from connection eventsstored in the connection events database. The extracted information maybe arranged and mapped to the same format.

In another example, an identifier for a first entity, such as asalesperson, an identifier for a second entity, such as a customer, anda location attribute may be retrieved from a first intermediary datastructure generated when information was extracted from connectionevents associated with the salesperson. A second location attribute maybe retrieved from a second intermediary data structure that wasgenerated when information was extracted from calendar events associatedwith the salesperson. The retrieved information may be combined andarranged into a data structure that matches a structure of informationused by the context data store to store context attributes associatedwith the salesperson.

In some implementations, the extracted context attributes may benormalized by expanding or transforming one or more data values includedin the extracted context attributes. Thus, abbreviations or identifiersspecific to the source of the context attribute may be replaced withgeneral representations used by the context store. For example, theacronym “LB” may be replaced with the text “Load Balancer.”Additionally, identifiers associated with users or entities may bereplaced with the names or user names of the users or entities.

At step 512, a context data store may be updated based on the normalizedinformation. Thus, once the context attributes have been extracted fromthe relevant connection events and calendar events and have beennormalized, the normalized data may be stored in the context data store.Once stored in the context data store, the normalized data may be usedby the context attribute interface. Thus, context attributes retrievedfrom physical connections and calendar connections between a user andanother entity may be used to modify a presentation of a mode ofcommunication used by the user, such as an instant message conversationor a video conference. Moreover, the context attributes retrieved fromphysical connections and calendar connections may be used to update ormodify one or more information feeds in a social network orcollaborative environment.

FIG. 6 shows a flowchart of an example of a method of extracting contextattributes from one or more information feeds, performed in accordancewith some implementations. As discussed above, information feeds mayinclude feed posts and other content generated by one or more entitiesassociated with an online social network or collaborative environment.For example, an information feed may include various posts and updatesrelated to a case that a group of users are working on. In someimplementations, a feed entity indexer may extract information fromvarious information feeds to build one or more indexes for informationstored in the information feeds. Furthermore, the extracted informationmay be used to update information stored in a context data store.

Accordingly, at step 602, content may be parsed and extracted from oneor more information feeds. In some implementations, a system component,such as a feed entity indexer, routinely indexes information feeds aspart of a background process. The feed entity indexer may also indexfeeds in response to a request issued by a context attribute interface.Thus, indexing of information feeds may occur automatically andperiodically, or in response to a request which may be triggered by auser action or communication. The data associated with an informationfeed may be stored in one or more data tables as part of a multi-tenantdatabase system. Thus, the data tables that store the information feedsmay be accessible to and modified by multiple users of an online socialnetwork or a collaborative environment, such as Chatter® provided bySalesforce.com®.

The feed entity indexer may query information feeds to identify andretrieve feed items, such as feed posts, made within each informationfeed. For example, a feed post may be made by a worker who has closed acase. In this example, the feed may be an entity feed that has beencreated for the case, and the feed post may be a data object thatindicates that the worker changed a status of the case from “open” to“closed”. The feed entity indexer may retrieve a feed item and parse andextract context attributes associated with one or more entities from thecontent of the feed item. Thus, the feed entity indexer may parse thecontents of a feed post, and extract any data values that identify oneor more entities. Such data values may be unique object identifiers thatidentify a user that made the post, or a user that was mentioned in thepost. Returning to the previous example, the feed post may be parsed andan identifier that identifies the user that closed the case may beextracted. It will be appreciated that other types of information may beparsed and extracted as well, such as mentions of users within the bodyof a post as well as mentions of products and services.

At step 604, the extracted information may be normalized and mapped to aformat or data structure that may be stored in a context data store. Assimilarly discussed above with reference to FIG. 5, step 510, mappingand normalizing the extracted context attributes may convert the contextattributes from multiple different formats used by multipleheterogeneous sources into a single uniform format used by the contextdata store. In some implementations, context attributes included in aninformation feed, or feed posts within an information feed, may includeinformation or data values that are industry domain or region specific.For example, different regions may use different practices for recordingtime and date information. Accordingly, time and date information may beextracted, arranged, and stored in a single uniform format used by thecontext data store. Thus, context attributes may be extracted frominformation feeds and information feed posts, and mapped to a formatused by the context data store. Moreover, abbreviations, identifiers,and expressions may be normalized. For example, the acronym “CPU” may beexpanded or transformed into the text “Central Processing Unit.”

At step 606, attributes of one or more information feeds may be parsed,extracted, and normalized. Thus, in addition to parsing and extractinginformation for feed items within a feed, general attributes associatedwith the information feeds themselves may be parsed, extracted, andnormalized. General attributes may be a feed topic or “Gist” of aninformation feed. For example, a “Gist” of an information feed may be atext string including a brief summary of the contents of the informationfeed that may be generated automatically or by a user. A feed topic maybe a few words identifying a topic for the information feed, such as acase reference number for the case or record for which the informationfeed has been generated. The general attributes may also includemetadata associated with the information feed, such as timestamp data,social network groups associated with the information feed, and usersassociated with the information feed. As similarly discussed withreference to step 602 and step 604, the attributes may be parsed fromthe information feeds, extracted to an intermediary data structure, andnormalized to a data structure that is compatible with the data storedin the context data store.

At step 608, a search index may be built for the extracted andnormalized information. Thus, the extracted information may be stored ina centralized location, such as a feed search index store. An index maybe generated for each type of information which may be a content basedindex, a metadata based index, or a combination of both. The indexeddata stored in the feed search index store may be accessible by acontext attribute interface application. Thus, the context attributeinterface application may access the feed search index store and use thegenerated indexes to perform one or more queries of the feed searchindex store to identify and retrieve context attributes. For example, ifa context attribute interface application is aggregating contextattributes which will be used to modify a presentation of a mode ofcommunication or a presentation of an information feed, the contextattribute interface application may query the feed search index store toidentify and retrieve context attributes that may provide a basis of themodification.

At step 610, a context data store may be updated based on the normalizedand extracted information. Thus, once the context attributes have beenextracted from the relevant information feeds and have been normalizedand indexed, a context attribute interface application may retrievecontext attributes relevant to a user's current context and store therelevant context attributes in a context data store. Once stored in thecontext data store, the normalized data may be used by the contextattribute interface. Thus, context attributes retrieved from informationfeeds may be stored and used to modify a presentation of a mode ofcommunication when relevant to a user's current context, such as aninstant messaging conversation thread or a video conference that theuser is currently conducting. Moreover, the context attributes retrievedfrom the information feeds may be used to update other information feedsor modify presentations of one or more information feeds for a specificuser or group of users' context, as discussed in greater detail in FIG.8.

FIG. 7 shows a flowchart of an example of a method of generating apresentation of a mode of communication based on context attributes,performed in accordance with some implementations. As set forth above, amode of communication may be an implementation of a communication tool,such as an instant messaging service. For example, the communicationtool may be the instant messaging service Chatter® Instant Messengerprovided by Salesforce.com®. The presentation of the mode ofcommunication or communication tool may refer to various functionalitiesand widgets included in a user interface screen, as well as avisualization or presentation of the user interface screen. Thus,context attributes may be used to modify functionalities presented to auser as part of the communication tool, and may be further used tomodify aesthetic attributes of the communication tool, such as fonts oftext, colors, and other formatting attributes.

Accordingly, at step 702, context attributes may be extracted for one ormore users of a communication tool. The context attributes may beextracted from a conversation thread in a particular mode ofcommunication. For example, several users may be using a communicationtool to engage in an instant message conversation. During theconversation, text may be generated by the users who are conversing andstored as part of a chat history. A parsing engine may parse the storedtext and extract one or more entities from the chat history. Thus, theparsing engine may perform a real-time analysis of the text stored inthe chat history and extract entities as the conversation is takingplace. For example, the parsing engine may compare text words in thechat history against a list of known entities that is maintained by theprovider of the communication tool, which may be an on-demand serviceprovider. If a word matches an entry in the list, it may be extractedand stored in an intermediate data structure. Thus, if a customer is aparticipant in an instant messaging conversation thread and mentionsthat he is having a problem with product XYZ, the parsing engine mayanalyze the text, determine that the term product XYZ matches an entryin a list of known entities, and extract product XYZ as a contextattribute.

Furthermore, context attributes may be extracted from information storedin the context data store. Each of the users participating in theconversation may have a unique identifier associated with the user'saccount that may be used to identify the user and retrieve informationassociated with the user. The identifier may be checked against datastored in a context data store to identify and retrieve contextattributes associated with the user. Thus, any context attribute storedin a data structure or data object that is associated with an identifierthat matches the user's identifier may be identified and retrieved. Forexample, a feed topic may have been stored in the context data storebecause a user authored a post in the information feed corresponding tothe feed topic. The feed topic may be stored in a data object thatincludes the user's identifier to indicate that the user authored thepost. The user's identifier may be matched with the identifier stored inthe data object, and the feed topic may be identified as a contextattribute that is relevant to the user. Accordingly, the feed topic maybe extracted and stored in an intermediary data structure.

In this way, context attributes associated with all users involved in aninstant message conversation may be aggregated in real-time while theconversation is happening. It will be appreciated that this may beperformed for any mode of communication or combination of modes ofcommunication. For example, context attributes may be extracted forusers involved in a communications session involving video conferencing,or a combination of video conferencing and content sharing via instantmessage chat.

At step 704, the extracted context attributes may be scored to determinean order that may be used when the context attributes are subsequentlyrendered as part of a user interface screen. Scoring the contextattributes may include assigning a weight to each of the extractedcontext attributes that determines an order of importance or relevanceamong the context attributes. For example, a context attribute with ahigher score may be ranked higher than a context attribute with a lowerscore. The context attributes may be scored and ranked based on thecontent of the conversation. For example, if a context attribute, suchas a product name, was mentioned by one of the users during theconversation, the context attribute may be scored and ranked highly. Thecontext attributes may also be scored and ranked based on a strength ofa relationship with a user participating in the conversation. Forexample, if a user participating in the conversation is also the authorof a feed post that was retrieved as a context attribute, that feed postmay be scored and ranked highly. It will be appreciated that the scoringand ranking process may use combinations of several factors to score andrank context attributes. For example, a company associated with aphysical connection may be scored highly if it was mentioned in theconversation thread and was created recently, as determined by itsassociated metadata.

At step 706, the scored context attributes may be filtered based on oneor more characteristics of a client device. In some implementations,characteristics of a client device may refer to a device form factor,capability of a device interface, applications installed on the clientdevice, or resources available to the device. The characteristics of theclient device may be used to filter the scored context attributes toensure that only context attributes that are compatible with the clientdevice are subsequently rendered and sent to the device. For example,the client device may be a mobile device used by a user. The scoredcontext attributes may include data objects such as images of mapsgenerated based on locations, or images generated based on other contextattributes. The scored context attributes may also include files ofdifferent formats, such as video files, and links to other data objectsor applications. Some of these types of context attributes might not becompatible with the mobile device. This may be because the mobile devicemight not have access to sufficient hardware or software resources toproperly display or provide functionality for a context attribute. Forexample, a context attribute may include a link to a resource, such as avideo, or an on-demand application. The mobile device might not have theappropriate application or plug-in to play the video. The mobile devicemight also not have a form factor or device interface capable ofexecuting the on-demand application.

In some implementations, a context attribute interface may determinewhich scored context attributes are not compatible with the mobiledevice. For example, the context attribute interface may compareinformation associated with a scored context attribute with apredetermined list of capabilities of the mobile device. Thepredetermined list of capabilities may be generated based on informationstored in a user's profile, which may indicate which applications havebeen installed on the user's mobile device. The context attributeinterface may determine which applications a scored context attributerequires based on information, such as metadata, associated with thescored context attribute. The metadata may be information such as a filename or extension. If the required application is not installed on themobile device, the context attribute interface may determine that thescored context attribute is not compatible with the mobile device. Thecontext attribute interface may perform one or more operations based onits determination of whether or not a scored context attribute iscompatible with the mobile device. For example, the context attributeinterface may remove the incompatible context attributes from thecontext data store, disable them prior to sending them to the mobiledevice, or store them in a separate data object in the context datastore.

At step 708, visual properties of a user interface may be modified andthe user interface may be rendered based on the scored contextattributes. As set forth above, the user interface may include severaluser interface components that provide a user with variousfunctionalities that may be used to communicate with other users. Forexample, the user interface components may enable a user to share text,images, files, and other content with other users that are participatingin a conversation. The presentation of the user interface components inthe user interface screen may be modified based on the scored contextattributes. Modifying the user interface in this way provides the userwith a user interface that has been customized based on the user'scurrent context. For example, context attributes associated with arecent service call or a product that was recently sold may be featuredmore prominently than older context attributes not mentioned in theconversation. Moreover, context attributes that are to be displayed inthe user interface screen may be selected based on their score. Forexample, a user interface component may only display the five contextattributes with the highest scores.

In addition to modifying which context attributes are presented in theuser interface screen and how prominently they are presented, the way inwhich user interface components are rendered may also be modified. Thus,aesthetic attributes of the user interface screen, or user interfacecomponents included in the user interface screen, may be modified basedon context attributes. For example, a font or color of text included inthe user interface components may be modified based on the contextattributes. In this example, if a product name is mentioned in aconversation thread, the product name may be identified as a highlyrelevant context attribute, and may be rendered as bold and italicizedfont. Furthermore, source contextual attributes and links to otherinformation or content may be included in the user interface screen andrendered. Thus, in addition to bolding and italicizing the product name,an embedded link may be rendered that provides a link to another dataobject, such as a knowledge database. The link may be displayed in avariety of ways, such as a pop-up or mouseover that provides a user withan active link or pop-up window when the user focuses on the productname in the user interface screen. In another example, a contextattribute may indicate that a user is using a mobile version of acommunication tool that executes on a mobile communications device, suchas a Smartphone. Thus, the user interface components included in theuser interface screen may be rendered in a format that is compatiblewith the display of the mobile communications device.

In some implementations, the user interface screen may be modified toinclude a data field that may be used to annotate a conversation threadwith contextual information. Thus, a data field may be presented withinthe user interface screen that presents the most relevant scored andranked context attributes. The data field may be configured to receivean input from a user that causes the communication tool to annotate theconversation thread with one or more selected context attributes. Thus,a user may select one of the presented context attributes and associatethe selected context attribute with one or more words in the text of theconversation thread. In this way, the user may be provided with theability to annotate a mode of communication with context attributesidentified and retrieved from various different sources, such as a CRMdatabase and an online social network. The annotations may be renderedas links or data objects that may be accessible to any usersparticipating in the conversation and viewing the conversation thread.Furthermore, the links and annotated information may be retained if theconversation thread is subsequently stored, as set forth in FIG. 8.

It will be appreciated that the modification of rendering of a userinterface may also be applied to forms and modes of communication otherthan text. For example, the presentation of a video conferencing toolmay be modified based on scored context attributes. Furthermore, theincorporation and rendering of a video conferencing window within aninstant messaging conversation thread may be modified based on scoredcontext attributes.

FIG. 9 illustrates an example of an image of a user interface screenthat may be rendered based on scored context attributes, in accordancewith some implementations. User interface screen 900 may include datafield 902 that displays a chat history for a current instant messagingconversation thread. In this instance, a salesperson is providing followup support for a product XYZ after visiting the customer's facility. Thechat history displays text shared by the salesperson and the customerduring the current conversation thread. The text “ACME” and “xyz” havebeen identified as context attributes associated with a company ACME anda product xyz. Accordingly, the presentation of the text has beenmodified and rendered in bold italicized font.

User interface screen 900 may further include data field 904 which maybe configured to display one or more context attributes that have beenextracted, scored, and rendered based on the contents of theconversation thread shown in data field 902. Data field 904 may beconfigured to provide links to additional data objects, or be configuredto tag text included in the conversation thread. Because the product xyzand the company Acme were mentioned in the conversation thread, contextattributes associated with product xyz and the company Acme have beenscored highly and are prominently featured in data field 904.

User interface screen 900 may also include data field 906 which may beconfigured to receive an input from a user that causes a systemcomponent, such as a context attribute interface, to post the contentsof the conversation thread to one or more information feeds. Asdiscussed in greater detail below in FIG. 8, the contents of theconversation thread may be incorporated into one or more informationfeeds, or posts within the information feeds. The contents of theconversation thread may also be used to modify a presentation of theinformation feeds.

Returning to FIG. 7, at step 710, the content of one or moreconversation threads may be monitored to detect changes in contextattributes. Thus, one or more system components, such as a contextattribute interface, may monitor the conversation thread in real time todetermine if additional context attributes are mentioned, or if thescoring of the context attributes should be changed. In response todetecting a change, the scoring and presentation of the contextattributes may be updated in real-time. For example, if a customer and asalesperson begin discussing a new product ABC, context attributesassociated with product ABC may be extracted, scored, and rendered aspart of a user interface screen.

FIG. 10 illustrates another example of an image of a user interfacescreen that may be rendered based on scored context attributes, inaccordance with some implementations. User interface screen 1000 mayprovide a customer or user with a presentation of a communication tool,such as an instant messaging service. The presentation may be modified,updated, and rendered based on the user's context. In someimplementations, the user's context may include a position, role, ortitle within an organization. Thus, the same instant messagingconversation thread may be rendered differently for different usersbased on their respective professional roles. For example, in contrastto user interface screen 900 which is specific to the salesperson'scontext, user interface screen 1000 may display a different presentationof the same instant messaging thread that is specific to the customer'scontext. Accordingly, a context attribute interface may generate andrender various different presentations of a user interface screen for aparticular instant messaging thread for various different usersassociated with the instant messaging thread. Each presentation may bespecific to an entity, such as a user or a group of users.

Accordingly, user interface screen 1000 may include data field 1002 thatdisplays a chat history for a current instant messaging conversationthread. As set forth above with reference to FIG. 9, data field 902, theconversation thread may be between a salesperson and a customerregarding support for a product or service that the customer haspurchased. For example, a salesperson may be providing additionalproduct support for product xyz to the customer after the salespersonrecently visited the customer's organization, ACME. Data field 1002 mayinclude data field 1004, in which the salesperson has replied to thecustomer's request for information and mentioned a resource, such as aYouTube® video that includes a presentation about product xyz.

User interface screen 1000 may further include data field 1006 which maybe configured to display one or more context attributes that have beenextracted, scored, and rendered based on the contents of theconversation thread shown in data field 1002. For example, data field1006 may include context attribute 1008 which has been presented inresponse to the salesperson mentioning an online video resourceassociated with the product the customer needs help with. As previouslydiscussed, the customer has asked for support for product xyz. Inresponse to the customer's inquiry, the salesperson has recommended thatthe customer view a YouTube® presentation referenced in an onlineresource, such as a Knowledge base provided by Salesforce.com®. The textentered by the salesperson may be parsed and analyzed in real time.Entities may be extracted from the text. For example, the product namexyz may be extracted. Based on the extracted entity name, a contextattribute interface may determine that a Knowledge base article existsfor product xyz. In some implementations, this may be accomplished byquerying a context data store for context attributes associated withproduct xyz. The context data store may store an indicator thatindicates that a Knowledge base article exists for product xyz, andprovides a pointer, link, or uniform resource locator (URL) to theKnowledge base article. One or more data values may be retrieved fromthe context data store, and rendered and displayed in data field 1008.For example, data field 1008 may display text indicating that aKnowledge base article exists for product xyz, and that the Knowledgebase article includes a YouTube® presentation associated with productxyz. Furthermore, data field 1008 may provide an interactive link to theKnowledge base article. Data field 1008 may be generated, rendered, anddisplayed in real-time and while the conversation is taking place.

Other context attributes may also be included in data field 1006. Forexample, data field 1006 may include context attributes which enableapplication services or provide links to applications or services thatthe customer subscribes to. In some implementations, a customer maysubscribe to one or more database services provided by an on-demandservice provider, such as Salesforce.com®. The products or services maybe one or more applications, such as enterprise applications.

For example, the on-demand service provider may provide the customerwith a data or content management system that may be used with a CRMdatabase. The product or service may also be an application that is partof a collaborative online environment. The application may track anentity, such as a project that the customer is working on or following.Products and services, such as applications, may be identified based onentities extracted from the conversation thread. For example, a contextattribute interface may extract the product name “xyz” and thecustomer's name or ID. The context attribute interface may query thecontext data store to determine what related services and products thecustomer subscribes to or has purchased. The context attribute interfacemay render and display data objects associated with any services andproducts that are identified as relevant to product xyz.

Accordingly, data field 1006 may include context attribute 1010 andcontext attribute 1012. Context attribute 1010 may provide a link to anapplication that the customer uses to track a project in which productxyz is being used. Context attribute 1012 may provide a link to aservice application that the customer uses to manage content associatedwith product xyz, such as the Service Cloud Console provided bySalesforce.com®. For example, the customer may use the Service CloudConsole to manage information about product xyz in a CRM database. Thus,in response to an entity, such as product xyz, being mentioned in aconversation thread, context attributes may be dynamically rendered andpresented in a user interface, and provide the user with user interfacecomponents that include interactive links. The user may select the linksto access one or more other applications.

FIG. 8 shows a flowchart of an example of a method of updating one ormore information feeds based on at least one conversation in acommunication tool, performed in accordance with some implementations.Thus, information, such as context attributes, may be parsed andextracted from one or more conversations that take place within thecontext of a communication tool, such as the instant messaging serviceChatter® instant messenger. The extracted information may be used toupdate one or more information feeds in an online social network, suchas Chatter®. Furthermore, the extracted information may be used toupdate a presentation of a group within the social network.

Accordingly, at step 802 a conversation thread may be parsed to extractone or more entities form the conversation thread. As similarlydiscussed above with reference to FIG. 7, a parsing engine may searchtext included in a conversation thread and extract relevant information.For example, a context attribute interface may include a parsing enginethat searches a chat history of a communication tool, parses thesearched text, and extracts any identified entities into an intermediarydata object. In one example, entities such as a user name, a product, acompany, an account, or a location may be extracted if mentioned withinthe conversation thread.

At step 804, the extracted entities may be normalized for a feed searchinterface. Thus, the extracted entities may be converted from multipledifferent formats used by multiple heterogeneous sources into a singleuniform format used by the context data store. For example, the names ofentities may be stored in a format that is industry domain or regionspecific. The entity names may be mapped to a format used by the contextdata store. As similarly set forth above, abbreviations, identifiers,and expressions may be normalized.

At step 806, weighted search attributes may be generated based on thenormalized extracted entities. In some implementations, a feed searchinterface may generate a query to be issued to a feed data store. Thequery may include several search terms that may be used to identify oneor more relevant information feeds that may exist in an online socialnetwork or collaborative environment. The search terms may be thenormalized extracted entities. Thus, entities that were mentioned in orparticipating in the conversation thread may be used as searchattributes that form the basis of a query for relevant informationfeeds.

Furthermore, weights may be assigned to the search attributes to returnthe information feeds most relevant to the conversation thread. Weightsmay be assigned to search attributes, such as extracted entities, byusing a static lookup table or computer-generated metrics related to thecontents of the conversation thread. For example, the system may monitora number of occurrences in a conversation thread and generate a weightbased on the number of occurrences. In another example, the system maymonitor other criteria, such as a how recently an entity was mentionedin the conversation thread. It will be appreciated that thecomputer-generated weights may be generated based on one criterion, or acombination of several criteria. Thus, the computer-generated metric maybe based on Chatter® group information feed content, Chatter® groupheader descriptions, associated information feed zones, or a proximityor collocation of multiple context attributes within a sentence boundaryor conversation thread. Alternatively, as a post processing step, weightcriteria could also be applied to rank search results prior to displayto a user. The computation of weights may also be specific to a group ofusers in an online social network, such as Chatter®. For example, if agroup is dedicated to a certain business process or topic, contextattributes relevant to that business process or topic may have higherrelevance. Extracted entities corresponding to those context attributesmay be given higher weights. The specificity of the search term weightcomputation and assignment may be specific as well as generic dependingon the targeted object. For example, the computation may be specific fora group of users of an online social network, such as a Chatter® group,or generic for a CRM data object, such as a case object accessible tomany users using different enterprise applications.

At step 808, one or more information feeds may be searched based on theweighted search attributes. Accordingly, a feed data store may besearched using the previously generated query having the weighted searchterms. Information feeds that include data values corresponding to theentities underlying the query may be identified and returned as resultsof the query. For example, if a user participating in the conversationthread has made posts in an information feed, subscribed to aninformation feed, or been mentioned in an information feed, thatinformation feed may be identified based on a data value identifying theuser that is stored either as content or metadata associated with theinformation feed. Similarly, information feeds associated with otherentities, such as companies, contacts, accounts, and products may alsobe identified. The results may be prioritized or ordered based on theweights assigned to the search terms. The results of the search mayinclude feed posts within information feeds, as well as the informationfeeds themselves.

In some implementations the results of the search may be presented to auser at a user interface. Thus, as discussed in greater detail belowwith reference to FIG. 10, the information feeds or feed posts that aremost relevant to the conversation thread may be presented to a user. Theuser may make a selection of one or more information feeds that shouldbe updated with information extracted from the conversation thread. Theselected feeds may be updated in response to receiving the selection.Alternatively, the feeds may be updated automatically according to apredetermined set of rules.

Accordingly, at step 810, a feed data store may be updated and a userinterface of a social network group may be refreshed. Thus, the storeddata associated with the selected information feeds and feed posts maybe updated to include information extracted from the conversationthread. In some implementations, the entire conversation thread and itsassociated metadata may be stored as a data object that is a child ofthe selected information feed or feed post. For example, if asalesperson and a customer are messaging each other via a communicationtool about the salesperson's most recent onsite visit, information fromthe conversation may be used to identify a feed post made by thesalesperson when he went to make the visit. The feed data store may beupdated so that the conversation thread is stored along with the feedpost. The feed post and the conversation thread may be stored in thesame data object, or as separate data objects that are parent-childobjects.

Furthermore, a user interface of a social network group may berefreshed. In some implementations, refreshing the user interface maycause the updated content to be rendered for a communication tool and anonline social network. Thus, a user interface for an instant messagingservice and an information feed in an online social network may berendered in the same browser session. Once rendered, a user may be ableto view and interact with the updated content. For example, a user of aninstant messaging service may be able to navigate or view a feed postwhich was tagged in the instant message conversation. Alternatively,other users, such as members of a group in an online social network, maybe viewing the information feed. Once the refresh has been triggered,the group of users may be able to view and access the instant messageconversation thread. In some implementations, the rendering process maygenerate one or more filters that allow users to browse and filterinformation feeds based on information included in instant messageconversation threads that have been tagged to or associated with theinformation feeds.

It will be appreciated that while FIG. 8 has been discussed withreference to updating data associated with an online social network,systems and methods disclosed herein may be used to update one or moreother types of databases. Thus, instead of a feed data store, a CRMdatabase, an enterprise application, or any other context attributeresource may be updated either alone or in combination.

FIG. 11 illustrates an example of an image of a user interface screenthat may be used to update information stored in information feeds of asocial network based on information extracted from a communicationstool, in accordance with some implementations. User interface screen1100 may include data field 1102 that displays a chat history for acurrent instant messaging conversation thread. User interface screen1100 may further include data field 1104 which may be configured todisplay one or more context attributes that have been extracted, scored,and rendered based on the contents of the conversation thread shown indata field 1102.

User interface screen 1100 may also include data field 1106 which may beconfigured to receive an input from a user that causes a systemcomponent, such as a context attribute interface, to display a datafield that enables the posting of the contents of the conversationthread to one or more information feeds in a social network.Accordingly, in response to receiving an input from a user, data field1108 may be presented in user interface screen 1100.

Data field 1108 may include data field 1110 which may be configured todisplay the results of a query of a feed data store that was performedbased on the contents of the conversation thread displayed in data field1102. Data field 1110 displays three feed posts which have beenidentified based on the entities included in the conversation thread,such as the customer's ID, the salesperson's ID, product xyz, andcompany ACME. Thus, the posts may have been authored by either thecustomer or the salesperson, or might relate to product xyz or companyACME. Data field 1110 may display various information about each feedpost, such as a social network group that the feed post belongs to, anda “Gist,” or brief summary, associated with the feed post.

Data field 1108 may also include data field 1112 which may present theuser with an option to select all presented information feeds or feedposts. Data field 1108 may further include data field 1114 which may beconfigured to update the selected information feeds or feed posts inresponse to receiving an input from the user. In this instance, if anyof the three feed posts that are presented are selected, they will beupdated with information from the conversation thread.

FIG. 12 illustrates an example of an image of feed posts that have beenupdated with information from a conversation thread, in accordance withsome implementations. As previously discussed, relevant feed posts madein a social network may be identified based on a conversation threadthat takes place in a separate mode of communication, such as an instantmessaging service. Image 1200 illustrates an example in which feed postsbelonging to feed topics in two different social network groups havebeen identified based on entities that were mentioned in theconversation thread.

Image 1200 includes data field 1202 which displays updated feedinformation for a first social network group. Data field 1202 includesfirst feed topic 1204 and second feed topic 1210. First feed topic 1204and second feed topic 1210 include feed posts 1206 and feed posts 1212respectively. Both feed posts 1206 and feed posts 1212 include entitiesthat match entities mentioned in the conversation thread. For example,feed posts 1206 include product xyz, while feed posts 1212 includeproduct xyz and posts made by the customer. Thus, both first feed topic1204 and second feed topic 1210 have been selected as relevant to theinstant messaging conversation thread and have been updated to storedata objects including the contents of the instant messagingconversation thread. Thus, data fields 1208 and 1214 have been generatedand rendered, and provide links to the data objects.

image 1200 includes data field 1203 which displays updated feedinformation for a second social network group. Data field 1203 includesthird feed topic 1216 and fourth feed topic 1222. Third feed topic 1216includes feed posts 1218 that mention product xyz. Thus, third feedtopic 1216 has been identified as relevant to the conversation threadand selected to be updated. Accordingly, a data object has been createdthat stores the conversation thread and data field 1220 has beenrendered to provide a link to the data object. Fourth feed topic 1222includes feed posts 1224 which do not mention any of the relevantentities and has not been identified as relevant to the conversationthread. Accordingly, fourth feed topic 1222 has not been updated.

FIG. 13 illustrates an example of an image of a user interface screenthat may be used to update information stored in CRM database based oninformation extracted from a communications tool. As similarly discussedabove with reference to FIG. 9, FIG. 10, and FIG. 11, user interfacescreen 1300 may include various data fields that display an instantmessaging conversation thread and context attributes which have beenidentified and displayed based on, among other things, the contents ofthe conversation thread. User interface screen 1300 may also includedata field 1302 which may be configured to receive an input from a userthat causes a system component, such as a context attribute interface,to display a data field that enables the posting of the informationassociated with the conversation thread to one or more other databases,such as a CRM database that may be associated with an entity mentionedin the conversation. For example, because product xyz was mentioned inthe conversation thread, a portion of a database in a CRM system that isassociated with product xyz may be accessed. In some implementations,the user may provide an input to provide feedback or sentiment analysisfor product xyz and interactions with sales representatives associatedwith product xyz. Accordingly, in response to receiving an input from auser, data field 1304 may be presented in user interface screen 1300.

Data field 1304 may include data field 1306 which provides informationabout one or more entities associated with the conversation thread. Theentity may be the most relevant entity or heaviest weighted search term,as determined by method 800. Because product xyz was mentioned multipletimes, it has been selected as the entity most relevant to theconversation thread. Accordingly, data field 1306 displays informationabout product xyz, such as its name. Furthermore, data field 1306 may beconfigured to receive an input from a user, such as a customer rating.User interface screen 1300 shows that the user has provided a rating ofthree stars.

Data field 1304 may further include data field 1308, which may receive arating associated with the conversation thread itself. Thus, thecustomer may rate his or her satisfaction with the salesperson. In someimplementations, data field 1304 may also include data field 1310 whichmay expand to allow a user to enter a text response.

Once the user has finished providing feedback, the user may provide aninput to data field 1312, which may be configured to update informationstored in the CRM database. Thus, the ratings provided by the user maybe stored in the CRM database and processed according to one or morestatistical operations to generate one or more metrics or performanceand satisfaction for product xyz and the salesperson.

While one or more implementations have been described by way of exampleand in terms of the specific embodiments, it is to be understood thatone or more implementations are not limited to the disclosedembodiments. To the contrary, it is intended to cover variousmodifications and similar arrangements as would be apparent to thoseskilled in the art. Therefore, the scope of the appended claims shouldbe accorded the broadest interpretation so as to encompass all suchmodifications and similar arrangements.

What is claimed is:
 1. A method for providing a contextual view for aninformation feed, the method comprising: hosting a conversation betweentwo or more users, the conversation generating text included in aconversation thread; extracting information and a plurality of entitiesfrom the generated text; assigning one or more weights to each of theextracted plurality of entities based on the contents of theconversation thread, the one or more weights providing a rank for eachof the extracted plurality of entities in a search of at least oneinformation feed; searching the at least one information feed based onthe weighted extracted plurality of entities to identify at least onerelevant information feed; and updating the at least one relevantinformation feed with the information extracted from the conversationthread.
 2. The method of claim 1, wherein the conversation is hosted byan instant messaging service and the at least one information feed isprovided by an online social network.
 3. The method of claim 1, whereinthe one or more weights are generated based on at least one of a staticlookup table and computer-generated metrics related to the contents ofthe conversation thread.
 4. The method of claim 3, wherein thecomputer-generated metrics are generated based on at least one of anumber of occurrences of an entity within the conversation thread and arecency associated with the occurrence of the entity.
 5. The method ofclaim 1, wherein an entity is at least one of the group consisting of: auser name, a product, a company, an account, a location, a project, anda connection event.
 6. The method of claim 1, wherein updating the atleast one relevant information feed comprises storing informationextracted from the conversation thread in a feed data store associatedwith the at least one relevant information feed.
 7. The method of claim1, wherein the extracted information includes the text of theconversation thread and a plurality of context attributes associatedwith the text of the conversation thread.
 8. The method of claim 1further comprising normalizing and mapping the extracted plurality ofentities from a first format to a second format.
 9. The method of claim1 further comprising providing one or more filters configured to filtera presentation of the updated at least one relevant information feedbased on the information extracted from the conversation thread.
 10. Themethod of claim 1 further comprising refreshing a user interface of anonline social network to render the updated at least one relevantinformation feed.
 11. The method of claim 1 further comprising receivinga selection from one of the two or more users, the selection selectingthe at least one relevant information feed to be updated.
 12. Anon-transitory machine-readable medium carrying one or more sequences ofinstructions which, when executed by one or more processors, cause theone or more processors to carry out the steps of: hosting a conversationbetween two or more users, the conversation generating text included ina conversation thread; extracting information and a plurality ofentities from the generated text; assigning one or more weights to eachof the extracted plurality of entities based on the contents of theconversation thread, the one or more weights providing a rank for eachof the extracted plurality of entities in a search of at least oneinformation feed; searching the at least one information feed based onthe weighted extracted plurality of entities to identify at least onerelevant information feed; and updating the at least one relevantinformation feed with the information extracted from the conversationthread.
 13. The machine-readable medium of claim 12, wherein the one ormore weights are generated based on computer-generated metrics relatedto the contents of the conversation thread, wherein thecomputer-generated metrics are generated based on at least one of anumber of occurrences of an entity within the conversation thread and arecency associated with the occurrence of the entity.
 14. Themachine-readable medium of claim 12, wherein updating the at least onerelevant information feed comprises storing information extracted fromthe conversation thread in a feed data store associated with the atleast one relevant information feed, and wherein the extractedinformation includes the text of the conversation thread and a pluralityof context attributes associated with the text of the conversationthread.
 15. The machine-readable medium of claim 12, wherein theconversation is hosted by an instant messaging service and the at leastone information feed is provided by an online social network, andwherein an entity is at least one of the group consisting of: a username, a product, a company, an account, a location, a project, and aconnection event.
 16. The machine-readable medium of claim 12, whereinthe steps further comprise receiving a selection from one of the two ormore users, the selection selecting the at least one relevantinformation feed to be updated.
 17. A system for providing a contextualview for an information feed comprising: a processor; and one or morestored sequences of instructions which, when executed by the processor,cause the processor to carry out the steps of: hosting a conversationbetween two or more users, the conversation generating text included ina conversation thread; extracting information and a plurality ofentities from the generated text; assigning one or more weights to eachof the extracted plurality of entities based on the contents of theconversation thread, the one or more weights providing a rank for eachof the extracted plurality of entities in a search of at least oneinformation feed; searching the at least one information feed based onthe weighted extracted plurality of entities to identify at least onerelevant information feed; and updating the at least one relevantinformation feed with the information extracted from the conversationthread.
 18. The system of claim 17, wherein the one or more weights aregenerated based on computer-generated metrics related to the contents ofthe conversation thread, wherein the computer-generated metrics aregenerated based on at least one of a number of occurrences of an entitywithin the conversation thread and a recency associated with theoccurrence of the entity.
 19. The system of claim 17, wherein updatingthe at least one relevant information feed comprises storing informationextracted from the conversation thread in a feed data store associatedwith the at least one relevant information feed, and wherein theextracted information includes the text of the conversation thread and aplurality of context attributes associated with the text of theconversation thread.
 20. The system of claim 17, wherein theconversation is hosted by an instant messaging service and the at leastone information feed is provided by an online social network, andwherein an entity is at least one of the group consisting of: a username, a product, a company, an account, a location, a project, and aconnection event.